我死了，然後我又回到了第一夜。這局城堡黑夜的遊戲，我已經記不清重來過幾次了。
九個玩家圍坐在長桌旁，這是最標準的九人局配置：三隻狼人、三個神職（預言家、女巫、獵人）、三個閉眼平民，採用嚴格的「屠邊規則」（狼人殺光所有神職或所有平民即獲勝）。桌上立著一枚象徵領導與秩序的警徽——在標準賽制中，警長擁有白天投票平票時 1.5 票的生殺大權，並負責在天亮時指定發言方向（由死左或死右開始，按順時針或逆時針進行）。更重要的是，全場貫徹嚴格的**「絕發規則」**：每個人只能在屬於自己的輪次說話，任何人不得插嘴打斷，每位玩家都必須在安靜的空氣中獨自承受全場的審視。
我是三隻狼之一。表面上我跟另外兩隻狼一樣，白天發言、晚上殺人、拼命偽裝成好人。但我有一個見不得光的祕密：我根本不會寫程式。
我是典型的「AI人」。
在九人局裡，真正的廝殺從天亮的第一刻就開始了。
天剛破曉，法官宣布進入**「上警環節」——玩家可以自由選擇是否競選警長。在講求競技的高階局中，好人陣營為了逼出狼人，前置位的平民或神職經常會「起跳預言家炸身份」**：假裝自己是真預言家，冷不防朝後置位扔出一顆「查殺」（指控對方是查驗出的狼人），觀察對方的臨場反應。
上一輪遊戲裡，坐在我前面的好人玩家就朝我甩了一張「查殺」。
如果是一個真正懂代碼架構的工程師，面對突如其來的質疑，他會冷靜拆解對方的邏輯矛盾、盤點場上的輪次與板子；然而身為「AI人」的我當場慌了手腳。在絕發的肅靜中，我手忙腳亂地把局勢丟進大型語言模型（LLM），催促它生成一段邏輯嚴密、用詞華麗的自辯，然後我照本宣科地唸了出來。
正如軟體工程大師 Martin Fowler 在其經典著作 Refactoring 中所寫：
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
（任何笨蛋都能寫出電腦看得懂的程式碼；優秀的工程師寫的是人類看得懂的程式碼。）
AI 替我生成的句子在語法上無懈可擊，修辭高級、架構漂亮，但本質上是空心的——它沒有立場，沒有對底層架構的真實洞察，只是一堆華麗詞藻的排列組合。場上的老玩家幾乎一眼就識破了我發言中的認知斷層：這是一個被查殺後慌亂調用 AI 唸稿的「爆狼發言」！
此時，狼人面臨著截然不同的命運分支：
我就這樣在絕對的死寂中趴在桌上倒牌，連開口說出最後一句 AI 辯詞的機會都沒有。
死掉之後，世界瞬間坍縮。當我再次睜開雙眼，眼前依然是第一夜那片冰冷的黑夜幕布——九個人、相同的身分底牌、完全重置的世界狀態，除了我，沒有人記得上一輪發生過什麼。這是一個死循環，一個沒有設定好終止條件的無限迴圈。
這正是我們 「2N1P」 團隊決定在今年鐵人賽展開這場挑戰的起點：我們不要再當那隻只會讓 AI 代筆、在自爆與無聲毒殺中反覆死去的狼。
看著眼前這場反覆重開的賽局，我不禁想到了當前的開源世界。現在的開源社群，何嘗不是一場**「大型開源狼人殺」**？空氣中瀰漫著濃濃的不信任感，每當維護者（Maintainer）打開 GitHub PR 列表，心中浮現的第一個念頭往往不是欣喜，而是戒備：這個提交者到底是一個真正理解系統的工程師，還是一隻躲在 AI 背後胡亂提 PR 的「狼」？
正如在開源界深耕多年、發起「源來適你」（OpenSource4You）社群的「開源大佬」chia7712，在其今年鐵人賽專文《不偷不搶不賭不嫖，依然不是我們要找的人》中所直言：
「基金會的錢不是用來養開源工程師，而是贊助優秀的軟體工程師... 如果你只是想來蹭每個月幾萬元的獎助金，交出一些用 AI 拼湊且自己都無法維護的 code 或缺乏實質貢獻的水題目，那我真心建議你另尋他地。社群資源有限，必須留給真正想捲起袖子做事的人。」
這段警語道破了無數維護者的痛點。2026 年的產業調查數據殘酷地揭示了現實：84% 的軟體工程師每天都在使用 AI 工具，生產環境中已有 41% 的程式碼由 AI 代筆生成；然而，在缺乏人類工程師嚴格審查下，團隊對 AI 產出的信心度僅僅只有 36%。
這正是當前所謂 「Vibe Coding」（氛圍編程） 所造成的信任災難：許多「AI人」沉迷於靠 Prompt 憑感覺一鍵生成幾百行炫麗代碼的快感，卻對執行期的記憶體流失、並發競爭條件（Race Conditions）與架構邊界一無所知。在開源維護中：
在 LLM 普及後，太多人利用 AI 自動化掃描專案，一口氣發出幾十甚至上百個 PR——修修文法、改改註解、做些不痛不癢的表面重構。這些人藉此刷漂亮了個人的 GitHub Contribution 圖表，但對開源專案而言，這無異於一場消耗維護者心力的「阻斷服務攻擊」（DoS）。真正的開源價值，永遠建立在解決那些沒人願意碰的硬骨頭上：消除 flaky tests、解決 release blockers、提升核心吞吐量。
為什麼開源世界的信任崩解得如此劇烈？因為我們缺乏一套清晰的博弈治理機制。各大專案對 AI 的衝擊反應不一：例如著名的 Zig 語言專案，因不堪大量空洞的 AI PR 侵擾，已經明文全面禁止任何由 LLM/AI 生成的 Pull Requests；而其他許多專案則選擇提高門檻，只接受熟人背書，或者要求提交者必須「拿自己的個人信譽做擔保」。
這正是為什麼我們選擇以「標準九人局」作為隱喻的原因：
面對充斥社群的「AI 人」，最簡單直接的做法當然是像 Zig 一樣全盤封殺，或者請不適任者「另尋他地」。這種嚴格的篩選是保護專案的必要手段，但我一直在想：難道這場人狼對立的死局，就只能永遠停留在互相猜忌與流放嗎？
借用東方哲學中「發願」的精神：誓願必須足夠廣大，才能支撐一個人走過艱鉅的淬鍊。而我自己，恰恰就是那隻在城堡黑夜中被無數次處死的「AI 狼」。如果我只是被社群掃地出門，世界上只會多一個怨懟的落榜者；但如果我們能把這場危機化為契機——以教化與轉化代替單純的排斥，帶領更多感到迷惘的新手學會誠實面對程式碼，學會將 AI 當作輔助思考的槓桿，而非掩蓋無知的面具，那麼一隻只會唸稿的狼，也能在開源熔爐的淬鍊下，蛻變成真正受人尊敬的開源工程師。
在軟體工程中，我所處的這場無限輪迴，本質上就是一個由狀態機（State Machine）控制的迴圈邏輯。我們可以用 Mermaid 狀態圖直觀看清包含「上警炸身份、自爆吞警徽、白天公投與女巫夜毒」的完整生死路徑：
將這套規則對應到軟體工程的狀態機控制邏輯，我們以本系列 Go 賽道（Kubernetes / Apache YuniKorn）的核心語法來定義狀態轉移與調諧迴圈（Reconciliation Loop）：
package main
import "fmt"
// EliminationCause records the specific rule trigger that ended the round.
type EliminationCause string
const (
SelfDetonationSwallowBadge EliminationCause = "SELF_DETONATION_SWALLOW_BADGE" // 自爆吞警徽（強制中斷白天、全場無警長）
DayVoteExileWithWords EliminationCause = "DAY_VOTE_EXILE_WITH_WORDS" // 第一天放逐投票（有遺言）
NightWitchPoisonSilent EliminationCause = "NIGHT_WITCH_POISON_SILENT" // 第二夜女巫毒殺（夜間死亡無遺言）
)
// CastronegroReconciliation manages the loop state until authentic capability is proven.
type CastronegroReconciliation struct {
Round int
NarratorAlive bool
}
// Reconcile checks observed state against desired state, triggering reset upon failure.
func (c *CastronegroReconciliation) Reconcile(cause EliminationCause) {
if !c.NarratorAlive {
fmt.Printf("State deviation [%s]: Resetting loop to Round 1 until genuine craft is proven.\n", cause)
c.Round = 1
c.NarratorAlive = true
}
}
這段精簡的調諧邏輯揭示了殘酷的現實：無論是因為慌亂自爆吞警徽、因為穿幫被公投放逐，還是被女巫在黑夜裡悄悄毒殺而無聲倒牌，只要 c.NarratorAlive 被判定為 false，系統就會立刻觸發 Reconcile()，將所有人的記憶抹除，讓一切重回起點。這其實與雲原生 Kubernetes controller 的調諧迴圈完全一致：不斷比對現狀（Actual State）與期望狀態（Desired State），直到收斂。
在現代 AI 輔助開發中，一個真正專業的**「監督式代理人閉環」（Supervised Agent Loop）** 必須嚴格走完五大階段：
$$\text{理解 (Comprehend)} \longrightarrow \text{規劃 (Plan)} \longrightarrow \text{執行 (Act)} \longrightarrow \text{評估 (Evaluate)} \longrightarrow \text{調整 (Adjust)}$$
上一輪的我之所以被村莊迅速識破，正是因為典型的 Vibe Coding 致命缺陷：
跳出這個無限輪迴的唯一路徑，不是把 Prompt 調校得更具迷惑性，而是徹底重構自己的工程大腦——學會成為這個閉環的領航者與嚴格審查員。
為了打破詛咒，我們團隊翻開了這份結合《2026 Junior工程師學習地圖》與社群實戰的修煉指南。這份地圖獨立於任何特定語法，專注於軟體開發不可動搖的基礎能力，並與 opensource4you / TAIONE GOSF 社群深耕的四大真實開源賽道無縫串聯：
AGENTS.md 韁繩工程（Harness Engineering）、Model Context Protocol (MCP) 以及規格導向開發（Spec-Driven Development, SDD），建立不可動搖的底層認知。這是一場狼人的救贖之旅。我們不再滿足於當一個只會複製貼上的 AI 魁儡。天又要黑了，當警長明天再次敲響發言鈴聲時，我希望自己說出的每一句話，都是自己親手敲過、測過、除錯過的真實思考。
"open source AI generated PR controversy" "Martin Fowler good programmers write code humans can understand" "Zig ban AI PR" "junior engineer roadmap 2026"
iThome鐵人賽
看影片追技術